home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Oct 90 / MacApp.Tech$ 10⁄5⁄90 / 2131-InsideOut⁄TDocument⁄-Oct90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  3.8 KB  |  69 lines  |  [TEXT/GEOL]
  1. Item    4724824                         5-Oct-90        06:04PDT
  2.  
  3. From:   D4727                           Philmont SW Mill, Jesse Feiler,PAS
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:    InsideOut/TDocument/MacApp.
  8.  
  9. I (sort of) agree with Jeff that the documentness as a runtime concept should
  10. be divorced (a lot) from disk icons and the disk files that lurk beneath them.
  11. That's why I still believe that the database should NOT be a descendant of
  12. TDocument.
  13.  
  14. The point about shared databases/which app. to open is valid, but a practical
  15. solution is not difficult.  Double-clicking on a database icon should open one
  16. application that is more significant than others with regard to the database:
  17. generally this would be a browser or possibly a housekeeping app.  After all if
  18. you want to muck around with the database, those are the tools you'd use.  If
  19. you want to do Accounts Payable, you'd double-click the A/P icon.  I don't see
  20. this as a major problem.
  21.  
  22. The main reason for NOT letting the database descend from TDocument is really
  23. defensive programming. If we look at much of the TDocument functionality --
  24. printing, saving, displaying in window(s), etc., these functions really don't
  25. apply to a database as a whole, particularly larger, multi-user databases.  I
  26. have (almost) never worked on an application where we allowed more than one
  27. saveable entity (which in practical terms is usually one record in a database
  28. view) to be open for editing at a time: you simply can't do that in a multiuser
  29. database without causing horrible problems. The original Macintosh model of
  30. opening a document, reading it into memory, and then fiddling with it with fast
  31. sub-second response time isn't appropriate to a database.
  32.  
  33. Now, you may say "what if I want to open a window which is a list of all
  34. customers in the database - just to review it, not to update it.  What's the
  35. document?"  My answer is it's a runtime document (in Jeff's terms) that has
  36. certain attributes, including the lack of save command (remember, no update).
  37. And in the MacApp world, it just might be a document-less TView. If you
  38. double-click on one customer name, you open a TWindow and TDocument which is
  39. that customer's view record which is saveable, printable, updateable, etc.  If
  40. you accept that we should keep unsaved (hence locked) parts of a database to a
  41. minimum, I think it's worth discouraging the use of the database as a TDocument
  42. descendant, since people may try to implement things like "save" and "print"
  43. for the whole database, and these commands should be discouraged.  At least in
  44. the large multi-user database world.
  45.  
  46. Another reason for focusing on TDocuments as database views is that this design
  47. becomes even more important in SQL, where the database has even less importance
  48. than it does in InsideOut: the individual tables (views) are truly the objects
  49. of concern.
  50.  
  51. Jeff Alger's comment of documentness being a run-time concept is very valuable,
  52. and becomes even more relevant when we look at the SQL world.  If I say "SELECT
  53. City, Best-Hotel, 2-best-hotel from Michelin-guide where country = "France"" I
  54. should create a run-time document.  That's what the user would expect.  A
  55. window should be opened; it should be printable; and save should be available
  56. (although its meaning is ambiguous: do I save the query or the results of the
  57. query? - probably options allow save/query, save/data in spreadsheet, save/data
  58. as text, etc.).
  59.  
  60. It seems to me that the only reason to descend a TDatabase from TDocument is to
  61. allow opening from the Finder.  We've found that it's trivial to set up the
  62. appropriate bundles and override TApplication.HandleFinderRequest to create our
  63. TApplication.fDatabase (actually gDatabase) in our applications. In addition,
  64. for our descendants of TDocument - which correspond to individual records in
  65. InsideOut views - we simply override TDocument.Save and are home free.
  66.  
  67. Jesse Feiler.
  68.  
  69.